1.11. Мессенджеры

ДЛЯ НОВИЧКОВНЕ ОБЯЗАТЕЛЬНОВ РАЗРАБОТКЕ

Всем

Мессенджеры

Понятие «мессенджер» (от англ. messenger — гонец, посыльный) исторически относилось к человеку, доставлявшему письма или устные сообщения. В цифровой среде это слово превратилось в обозначение программного продукта, решающего задачу синхронного и асинхронного обмена структурированными данными между пользователями в реальном времени.

Сегодня мессенджеры — не просто приложения. Они образуют информационно-коммуникационную инфраструктуру, сопоставимую по значимости с электронной почтой, DNS или HTTP. В них интегрируются:

каналы массовой коммуникации (каналы, рассылки),
системы управления (боты, команды),
платформы микросервисов (API, вебхуки, облачные функции),
интерфейсы для бизнеса (чат-боты, CRM-интеграции),
средства цифровой идентификации (Telegram Passport, VK ID).

По сути, современный мессенджер — это гибрид социальной сети, клиент-серверного приложения и распределённой системы обмена сообщениями, построенной на строгих протоколах и высокодоступных архитектурах.

1. Исторический контекст

1.1. Ранние системы

Первой массовой системой мгновенных сообщений (англ. Instant Messaging, далее — IM) считается ICQ (1996, Mirabilis). Слово ICQ — игра слов: «I Seek You» → Ай-Си-Кью.
ICQ ввела ключевые концепции:

Список контактов (buddy list),
Статусы присутствия (online/offline/away),
Оффлайн-сообщения (сообщения, доставляемые при следующем подключении),
Файлообмен «в лоб» (P2P-передача без сервера-посредника).

Архитектура ICQ была централизованной: клиенты подключались к серверам Mirabilis через проприетарный бинарный протокол поверх TCP. Это обеспечивало скорость, но делало систему уязвимой к централизованному контролю и отказам.

Параллельно развивалась IRC (Internet Relay Chat, 1988), изначально задуманная как инструмент для технического общения в университетских сетях. В отличие от ICQ, IRC:

работала по модели клиент–сервер–сервер (серверы могли объединяться в сеть),
поддерживала каналы (channels) — публичные или приватные чаты с именами (#linux, #help),
не хранила историю — сообщения существовали только «в эфире».

IRC до сих пор используется в open-source-сообществах и DevOps-экосистемах (например, Libera.Chat), демонстрируя жизнеспособность децентрализованных, текстово-ориентированных протоколов.

1.2. Эра веб-платформ: Jabber/XMPP, Facebook Chat

В 1999 году появился Jabber — первая открытая, децентрализованная система IM на основе стандарта XMPP (Extensible Messaging and Presence Protocol).
XMPP построен на XML и использует модель federated identity: любой может запустить свой сервер (например, user@myserver.org), и он будет совместим с другими доменами — как в электронной почте (user@gmail.com ↔ friend@yandex.ru).

Ключевые особенности XMPP:

Расширяемость: через XML-namespace можно добавлять функции (видеозвонки, файлы, IoT-управление),
Присутствие (presence): сервер отслеживает онлайн/оффлайн-статус, рассылает уведомления подписчикам,
Очереди доставки: сервер хранит сообщения для оффлайн-получателей.

Facebook Chat (2008) изначально использовал XMPP как транспорт — что позволяло сторонним клиентам (Pidgin, Adium) подключаться к фейсбуковским чатам. Позднее, стремясь к контролю и монетизации, Facebook закрыл XMPP-шлюз (2014), перейдя на проприетарный протокол поверх MQTT.

1.3. Мобильная революция: WhatsApp, Viber, WeChat

С приходом смартфонов ключевым требованием стало минимизация энергопотребления и трафика.
WhatsApp (2009) сделала ставку на:

привязку к номеру телефона (вместо логина/email),
оптимизированный бинарный протокол поверх шифрованного TLS-соединения,
мультиплатформенность без потери истории (пересылка базы SQLite при смене устройства).

С 2016 года WhatsApp внедрил сквозное шифрование (E2EE) на основе протокола Signal — что стало отраслевым стандартом.

WeChat (Китай, 2011) пошёл дальше: превратил мессенджер в «суперапп» — платформу, объединяющую:

платежи (WeChat Pay),
мини-программы (аналог PWA без браузера),
госуслуги (медицинские записи, налоги),
корпоративные чаты (WeCom).

Это показало: мессенджер может стать операционной системой повседневной жизни.

1.4. Современный этап: Telegram, Signal, Matrix

Telegram (2013) предложил:

облачную синхронизацию всех данных (сообщений, медиа, файлов),
клиент-серверную и P2P-архитектуры в одном приложении,
открытые API и Bot Platform,
MTProto — собственный протокол с кастомной криптографией (обсуждаемый, но прошедший аудиты).

Signal (2014, как приложение; протокол с 2013) сделал ставку на максимальную приватность:

сквозное шифрование по умолчанию для всех чатов,
минимальный сбор метаданных,
открытый исходный код (клиент и сервер),
федеративная архитектура в будущем (Signal Foundation работает над децентрализацией).

Matrix (2014–2019) — попытка создать открытую, федеративную замену Slack и Discord:

трафик шифруется (E2EE через Olm/Megolm),
серверы могут объединяться в сеть (например, @user:matrix.org ↔ @admin:gov.uk),
совместимость с IRC, Slack, Telegram через шлюзы,
используется в ЕС, Швейцарии, NASA для внутренней коммуникации.

Эволюция показывает: мессенджеры прошли путь от утилиты к инфраструктуре, от приватного общения к публичной коммуникации, от клиента к платформе.

2. Что такое мессенджер

Мессенджер — это клиент-серверное (или peer-to-peer) программное приложение, реализующее протокол обмена структурированными сообщениями в реальном или псевдореальном времени, с поддержкой аутентификации, управления сессиями, доставки, подтверждения получения и хранения истории.

Ключевые отличия от смежных понятий:

Объект	Мессенджер	Электронная почта	Форум / чат-платформа
Время доставки	мгновенное (ms–s)	отложено (s–min)	асинхронное (min–days)
Модель присутствия	онлайн/оффлайн, typing indicators	отсутствует	часто отсутствует
История	хранится локально/в облаке, синхронизируется	на сервере отправителя/получателя	публично, в базе форума
Топология	1:1, 1:М, М:М (чаты, группы)	1:М (рассылки)	М:М (темы, треды)
Протоколы	XMPP, Signal, MTProto, MQTT, WebSocket	SMTP, IMAP, POP3	HTTP(S), WebSocket, Long Polling

Важно: не всякий чат — мессенджер.
Например, чат в Steam — модуль внутри игровой платформы, использующий проприетарный протокол поверх HTTPS/WebSocket. Он не поддерживает федерацию, не имеет независимой идентификации, не синхронизируется вне экосистемы Steam. Это встроенный чат, а не автономный мессенджер.

3. Система мгновенных сообщений (IM)

Любой масштабируемый мессенджер состоит из следующих слоёв:

3.1. Клиент (Client)

GUI/CLI: интерфейс (десктоп, мобильный, веб) или консоль (irssi, matterhorn).
Состояние сессии: токены авторизации, кэш сообщений, список контактов.
Криптографический модуль: генерация ключей, шифрование/дешифрование, верификация отпечатков.
Транспортный адаптер: выбор протокола (WebSocket, MQTT, HTTP/2, QUIC), управление реконнектами, backoff-логикой.

3.2. Транспортный уровень

Поддержка нескольких транспортов — обязательна для отказоустойчивости:

Протокол	Преимущества	Недостатки	Примеры использования
WebSocket	Full-duplex, низкая задержка, стандарт HTML5	Требует поддержки на сервере, уязвим к DoS	Telegram Web, Slack, Discord
HTTP Long Polling	Работает через прокси/NAT, совместим со старыми серверами	Высокая задержка, overhead заголовков	Старые версии WhatsApp Web
MQTT	Минимальный overhead, publish/subscribe, энергоэффективен	Требует брокера (Mosquitto, EMQX)	Facebook Messenger (внутренне), IoT-мессенджеры
QUIC (на базе UDP)	Устойчив к смене IP (роуминг), 0-RTT handshake	Новый, не везде поддерживается	Telegram (экспериментально), Google Messages

Выбор транспорта влияет на latency, throughput, battery consumption и firewall traversal.

3.3. Сервер (Backend)

Современный backend мессенджера — это микросервисная архитектура:

Auth Service — выдача токенов (JWT, OAuth2), двухфакторная аутентификация.
Presence Service — отслеживание онлайн-статуса через heartbeat-сообщения (ping/pong).
Message Router — маршрутизация: отправитель → получатель, группа → все участники.
Storage Layer — гибрид: hot storage (Redis/Cassandra для последних сообщений), cold storage (S3/MinIO для медиа), metadata (PostgreSQL).
Push Gateway — интеграция с FCM (Firebase), APNs (Apple), HMS (Huawei) для уведомлений при оффлайне.
Bot Engine — sandbox-выполнение кода (WebAssembly, isolates), webhook-доставка.

Пример масштаба: Telegram обрабатывает > 1 млрд сообщений в день. Для этого используется кластер из тысяч серверов в data-центрах по всему миру, с шардированием по user_id и гео-маршрутизацией.

3.4. Протокол обмена

Протокол определяет:

формат сообщения (JSON, Protocol Buffers, TL-Schema),
порядок установки соединения (handshake),
подтверждение доставки (acks),
управление группами (join/leave/sync),
механизмы шифрования.

Например, в MTProto 2.0 (Telegram):

каждое сообщение сериализуется в TL-структуру (Type-Language),
шифруется AES-256-IGE с кастомным padding,
подпись формируется через SHA-256 и 128-битный msg_key,
используется sequence number для защиты от replay-атак.

В Signal Protocol:

используется Double Ratchet Algorithm: комбинация Diffie-Hellman Ratchet и Symmetric-Key Ratchet,
каждый сеанс имеет уникальные корневой, цепной и сообщение-ключ,
forward secrecy и future secrecy гарантируются ротацией ключей после каждого сообщения.

4. Как работает доставка сообщения: пошаговый разбор

Рассмотрим путь сообщения "Привет!" от пользователя А (мобильный) к пользователю Б (десктоп), в мессенджере с E2EE (например, Signal).

Клиент А:
- Формирует plaintext-сообщение.
- Получает prekey bundle пользователя Б с сервера (содержит signed prekey, identity key и one-time prekey).
- Выполняет три DH-обмена (X3DH), формирует session key.
- Шифрует сообщение с помощью Double Ratchet → ciphertext + заголовок (sender, counter, chain key).
- Отправляет через зашифрованное TLS-соединение на сервер.
Сервер:
- Проверяет аутентичность клиента А (токен).
- Определяет онлайн-статус Б:
  - Если онлайн — пушит ciphertext напрямую через WebSocket.
  - Если оффлайн — кладёт в очередь (Kafka/RabbitMQ), запускает push-уведомление через FCM/APNs.
Клиент Б:
- Получает ciphertext.
- Расшифровывает заголовок, сверяет chain key и counter.
- Применяет ratchet, получает симметричный ключ.
- Расшифровывает тело → "Привет!".
- Отправляет ack (подтверждение получения) — для обновления состояния «доставлено/прочитано».

Этот процесс занимает 50–300 мс в среднем — благодаря оптимизациям: connection pooling, TLS session resumption, binary serialization.

5. Сквозное шифрование (End-to-End Encryption, E2EE)

5.1. Что это — и чего это не даёт

E2EE — криптографическая схема, при которой только отправитель и получатель могут прочитать содержимое сообщения. Серверы (и злоумышленники с доступом к ним) видят только зашифрованный blob и метаданные (время, размер, адресаты).

Что шифруется:

текст сообщений,
медиаконтент (фото, видео, голосовые),
вложения,
иногда — имена файлов и превью.

Что не шифруется (метаданные):

кто с кем общается (graph связи),
когда и как часто,
время онлайн,
IP-адреса (если не используется TOR/обфускация),
group ID, channel ID.

Пример: в WhatsApp метаданные передаются Meta — и это легально, т.к. политика конфиденциальности это разрешает. E2EE защищает содержание, но не факт коммуникации.

5.2. Реализации

Система	Протокол	E2EE по умолчанию?	Открыт ли сервер?
Signal	Signal Protocol	✅	✅
WhatsApp	Signal Protocol (адаптированный)	✅	❌
Telegram	MTProto (только в «Секретных чатах»)	❌ (обычные чаты — client-server)	❌ (сервер закрыт)
iMessage	Apple iMessage Protocol (на базе Curve25519)	✅	❌
Matrix (с E2EE)	Olm/Megolm	опционально	✅

Почему Telegram не использует E2EE везде?

Облачная синхронизация: чтобы сообщение было доступно на всех устройствах, оно должно храниться на сервере в расшифрованном виде (или с ключом, известным серверу).
Групповые чаты: в секретных чатах Telegram группы невозможны — E2EE не масштабируется на 200k участников без компромиссов.

Это не «недостаток», а архитектурный выбор: удобство и функциональность vs. максимальная приватность.

6. Переписка, история, группы и каналы: модели данных

6.1. Переписка (chat/dialog)

1:1-диалог: упорядоченная хронологическая последовательность сообщений.
— В базе: таблица messages с полями: id, from_user_id, to_user_id, timestamp, content, status (sent/delivered/read).
— Индексы по (from_user_id, to_user_id, timestamp) для быстрого диапазонного поиска.
История: может храниться:
- локально (SQLite на устройстве — безопасно, но не синхронизируется),
- на сервере (PostgreSQL + S3 — удобно, но требует доверия).
  — Telegram использует гибрид: последние 100 сообщений — в RAM-кэше сервера, остальное — в blob-хранилище.

6.2. Группы

Малые группы (<200 участников):
— Обычно работают как «транслируемый диалог»: сервер рассылает каждое сообщение всем участникам.
— Управление: add_user, kick, promote_admin — команды с проверкой прав.
Крупные группы / супергруппы (до 200 000+):
— Используют pub/sub-модель: участники подписываются на topic (например, group:12345).
— Сервер публикует сообщение в Kafka-topic → все подписчики получают копию.
— Пример: Telegram супергруппы, Discord серверы.

6.3. Каналы

Односторонняя рассылка: один или несколько авторов → множество подписчиков.
Нет ответов (или только через комментарии в отдельном чате).
Хранение: оптимизировано под read-heavy нагрузку — CDN-кеширование превью, сегментация по регионам.
Метрики: просмотры, ретрансляции, engagement rate — критичны для медиа и брендов.

7. Как получить, установить и использовать мессенджер

7.1. Способы получения

Платформа	Способы установки
Android	Google Play, APK (с сайта), F-Droid (Signal), ADB install
iOS	App Store, TestFlight (бета), enterprise-сертификаты (редко)
Windows/macOS/Linux	Installer (.exe, .dmg, .deb/.rpm), AppImage, Snap/Flatpak, исходники (build from source)
Web	Progressive Web App (PWA), iframe-встраивание (не рекомендуется из-за безопасности)

Рекомендация: всегда проверяйте цифровую подпись пакета (например, gpg --verify telegram.tar.xz.sig). Для Signal — используйте официальный репозиторий.

7.2. Первый запуск: что происходит «под капотом»

Запрос разрешений (контакты, камера, уведомления).
Генерация device key pair (Ed25519 или Curve25519).
Регистрация номера/логина → получение user ID и auth token.
Синхронизация контактов: хэширование номеров (SHA-256), отправка на сервер для поиска совпадений (contact discovery).
Загрузка списка чатов и последних сообщений (pagination + lazy loading).

7.3. Базовые операции — как они реализованы

Действие	Техническая реализация
Отправка сообщения	serialise → encrypt → send via WebSocket → wait for `msg_id` и `seq_no` → обновить UI с временным ID → после ack — заменить на постоянный
Редактирование	отправка нового сообщения с флагом `edit_of: old_msg_id`; сервер заменяет старое (если разрешено политикой)
Удаление для всех	multicast-сообщение `delete_request` → клиенты удаляют локально; сервер помечает как `deleted_at` (но может сохранять для аудита)
Поиск по истории	full-text индекс (PostgreSQL `tsvector`, Elasticsearch); локальный поиск — через SQLite FTS5

Часть 2. Глубокая архитектура мессенджеров

1. Сравнительный анализ протоколов: MTProto, Signal Protocol и Matrix (Olm/Megolm)

Выбор протокола — это не инженерная деталь, а стратегическое решение, определяющее баланс между безопасностью, масштабируемостью, удобством и контролем. Ниже — техническое сопоставление трёх ключевых подходов.

1.1. MTProto 2.0 (Telegram)

Структура сообщения:
Каждое сообщение в MTProto 2.0 состоит из следующих частей:

+------------------+------------------+------------------+------------------+
|  auth_key_id (8) | msg_key (16)     | encrypted_data   | padding (0..15)  |
+------------------+------------------+------------------+------------------+

auth_key_id — идентификатор долгоживущего ключа аутентификации (сервер генерирует при регистрации устройства).
msg_key — 128-битный хэш от первых 32+16 байт encrypted_data, используется для генерации AES-ключа.
encrypted_data — результат шифрования всего содержимого (включая message_id, seq_no, obj) через AES-256-IGE.
padding — случайные байты для предотвращения анализа по длине.

Криптографический стек:

Симметричное шифрование: AES-256 в режиме IGE (Infinite Garble Extension) — не стандартный режим (обычно используют GCM или CTR), но устойчивый к ошибкам при передаче.
Хэш-функция: SHA-256 → усечение до 128 бит для msg_key.
Обмен ключами: при первом подключении — Diffie-Hellman (2048-bit), затем — долгоживущий auth_key.

Критика и ответы:

Уязвимость IGE к атакам padding oracle?
Нет — Telegram использует кастомный padding (случайные байты + контрольная сумма), а msg_key привязан к данным, поэтому подмена padding не пройдёт проверку. Аудиты (NCC Group, 2021) не выявили практических атак.
Почему не Signal?
MTProto оптимизирован под облачную синхронизацию: сервер может расшифровать сообщение для доставки на другие устройства пользователя. В Signal это невозможно без утечки ключа.

Итог: MTProto — компромисс в пользу масштабируемости и удобства при сохранении высокой, но не максимальной приватности. Безопасен при корректной реализации.

1.2. Signal Protocol (WhatsApp, Signal, Google Messages)

Ядро — Double Ratchet Algorithm:

X3DH (Extended Triple Diffie-Hellman) — инициализация сессии:
- У каждого участника: identity key (IK), signed prekey (SPK), one-time prekeys (OPK × N).
- При первом сообщении отправитель берёт один OPK получателя → вычисляет 4 общих секрета → комбинирует в master secret.
- Гарантирует forward secrecy и асинхронный старт (даже если получатель оффлайн).
Double Ratchet — поддержка сессии:
- DH Ratchet: при каждом ответе стороны обмениваются новыми ephemeral ключами → сдвиг цепи.
- Symmetric-Key Ratchet: каждый сдвиг порождает цепочку ключей (K₁ → K₂ → K₃…), по одному на сообщение.
- Если сообщения теряются — используется KDF (Key Derivation Function) для «догоняющего» расчёта.

Формат сообщения (Signal Message):

message SignalMessage {
  optional bytes sender_identity_key = 1;
  optional uint32 counter = 2;       // sequence number
  optional bytes ciphertext = 3;     // AES-256-GCM
  optional bytes mac = 4;            // HMAC-SHA256 для целостности
}

Шифрование: AES-256-GCM — стандарт де-факто, обеспечивает конфиденциальность + аутентификацию.

Преимущества:

Forward secrecy: компрометация одного ключа не раскрывает прошлые сообщения.
Future secrecy (break-in recovery): если ключ украден, новые сообщения остаются защищёнными.
Асинхронность: отправка возможна без online-статуса получателя.

Ограничения:

Масштабирование на большие группы сложно: Signal использует Sender Keys (один ключ на группу), что снижает forward secrecy.
Облачная синхронизация требует хранения зашифрованных бэкапов (например, в iCloud с паролем) — но ключи не передаются серверу.

1.3. Matrix: Olm (1:1) и Megolm (группы)

Matrix решает главную проблему Signal — масштабируемость групп с E2EE.

Olm — аналог Signal Protocol для 1:1-чатов (Double Ratchet + Curve25519).
Megolm — инновация для групп:
- Генерируется session key → разбивается на chain key → каждый шаг цепи даёт message key.
- Ключи шифруются отдельно для каждого участника через их Curve25519 public key и рассылаются в «prekey room».
- При добавлении нового участника — создаётся новая session, старые сообщения недоступны (plausible deniability).

Формат события (с E2EE):

{
  "type": "m.room.encrypted",
  "content": {
    "algorithm": "m.megolm.v1.aes-sha2",
    "session_id": "g0v3rn...",
    "ciphertext": "U2FsdGVkX19...",
    "device_id": "XYZ123"
  }
}

Декодирование требует:

Получить session key (из зашифрованного события m.room_key).
Расшифровать ciphertext через AES-256-CBC + HMAC-SHA256.

Плюсы:

Полная децентрализация: любой может запустить homeserver.
Совместимость с LDAP, SSO, SAML — для корпоративного use case.
Открытые спецификации (Apache 2.0), реализации на Rust (Conduit), Go (Dendrite), Python (Synapse).

Минусы:

Высокая сложность развёртывания.
Проблемы с latency при федерации (сервер A → сервер B → сервер C).
Не все клиенты поддерживают E2EE по умолчанию.

Вывод по протоколам:

Signal — gold standard для приватности в 1:1.

MTProto — оптимизация под UX и облачные функции.

Matrix — единственное открытое решение для E2EE в распределённых группах.

2. Боты: от простых команд до автономных агентов

Бот — это не «программа в чате», а микросервис с интерфейсом через мессенджер. Его архитектура зависит от платформы, но общие принципы едины.

2.1. Модели взаимодействия

Тип	Описание	Примеры	Недостатки
Webhook	Сервер бота регистрирует URL → мессенджер отправляет POST-запросы при событиях	Telegram Bot API, Slack Events API	Требует публичного HTTPS-эндпоинта, уязвим к DoS
Long Polling	Клиент периодически опрашивает `/getUpdates`	Telegram (старый режим), VK Callback API	Задержка, высокая нагрузка на клиент
WebSocket Streaming	Постоянное соединение, push-события в реальном времени	Discord Gateway, Matrix Sync API	Сложность управления state, reconnect-логика
Server-Sent Events (SSE)	Односторонний поток от сервера к клиенту	Некоторые enterprise-решения	Поддержка не везде, нет обратного канала

2.2. Архитектура бота на примере Telegram Bot API

Регистрация:
- /botfather выдаёт BOT_TOKEN.
- Вызов setWebhook → указание https://your-server.com/webhook.
Обработка входящего события (пример на Python, Flask):

from flask import Flask, request
import requests

app = Flask(__name__)
BOT_TOKEN = "123456:ABC-DEF1234ghIkl-zyx57W2v1u123ew11"

@app.route('/webhook', methods=['POST'])
def webhook():
    update = request.json
    chat_id = update['message']['chat']['id']
    text = update['message']['text']

    if text == '/start':
        reply = "Привет! Я бот для анализа логов."
    elif text.startswith('/parse '):
        log = text[7:]
        result = parse_log(log)  # ваша бизнес-логика
        reply = f"Результат: {result}"
    else:
        reply = "Неизвестная команда."

    # Отправка ответа
    requests.post(
        f'https://api.telegram.org/bot{BOT_TOKEN}/sendMessage',
        json={'chat_id': chat_id, 'text': reply}
    )
    return '', 200

State management:
- Для диалогов («Введите логин», «Теперь пароль») используется:
  - In-memory dict (для dev),
  - Redis (user_id → state + data),
  - PostgreSQL (sessions table).
Rate limiting:
Telegram ограничивает:
- 30 сообщений/сек на бота,
- 20 сообщений/мин в личку,
- 1 сообщение/сек в группу (если не админ).
  Реализуется через token bucket (например, ratelimit в Python).

2.3. Продвинутые сценарии

Интеграция с внешними API:
Бот как прокси к Jira, GitLab, ELMA365 — с OAuth2 авторизацией и caching.
Голосовые интерфейсы:
Telegram поддерживает voice_note → можно подключить ASR (Whisper API) → транскрибировать → обрабатывать.
Автономные агенты:
Бот на базе LLM (например, Llama 3 в GGUF) + RAG по внутренним документам — работает полностью on-premise, без облака.

Бот — это точка входа в систему. Его код может быть тонким адаптером к enterprise-бэкенду.

3. Безопасность мессенджеров: не только шифрование

Сквозное шифрование защищает содержимое, но атаки чаще направлены на метаданные, человеческий фактор и инфраструктуру.

3.1. Уязвимости транспортного уровня

Атака	Описание	Защита
SS7 Exploitation	Использование уязвимостей в сигнальной системе №7 (мобильные сети) для перехвата SMS-кодов	Отказ от SMS-2FA, переход на TOTP или FIDO2
SIM Swap	Мошенник убеждает оператора перевыпустить SIM на свой паспорт	PIN-код у оператора, уведомления о смене SIM
Stingray (IMSI-catcher)	Поддельная BTS-станция перехватывает трафик GSM/3G	Использование 4G/5G (требуют mutual auth), VoIP-звонки
TLS Interception	Корпоративный MITM через доверенный CA	Certificate pinning (HPKP устарел, но можно через `NetworkSecurityConfig` в Android)

3.2. Утечки метаданных

Даже при E2EE метаданные раскрывают:

Социальный граф: кто с кем общается, частота, длительность сессий.
География: IP-адрес → город (даже при CDN — handshake-пакеты идут напрямую).
Поведенческие паттерны: время онлайн, typing indicators, reaction time.

Пример: исследование MIT (2020) показало, что по метаданным WhatsApp можно с 95% точностью определить, является ли пользователь врачом, учителем или активистом.

Меры защиты:

Обфускация трафика: Telegram использует obfs4-подобные методы в «прокси-режиме».
Delay pools: искусственная задержка отправки для маскировки паттернов.
Минимизация данных: Matrix позволяет отключать presence, typing indicators, last seen.

3.3. Атаки на клиент

Clipboard hijacking: вредоносное ПО подменяет скопированный Bitcoin-адрес.
Screen overlay: фишинговое окно поверх чата (Android Accessibility API).
Zero-day в WebView: эксплуатация уязвимостей в компоненте для отображения ссылок.

Защита:

Sandboxing (Android SELinux, iOS App Sandbox),
Отказ от WebView для критичных операций (лучше встроенный браузер с CSP),
Regular security audits (например, Cure53 для Signal).

4. Федерация и децентрализация

4.1. Что такое федерация?

Федерация — это интероперабельность между независимыми серверами, как в электронной почте:

user@server1.org ↔ friend@server2.net ↔ admin@gov.local

Каждый домен управляет своими пользователями, но может обмениваться сообщениями с другими.

4.2. Реализации

Система	Поддержка федерации	Статус
XMPP	Полная (стандарт)	Устаревает, но жив (Conversations, Snikket)
Matrix	Полная (homeserver federation)	Активно развивается, используется в ЕС
ActivityPub	Для постов (Mastodon), не для чатов	Чаты в разработке (Movim, Misskey)
Briar	P2P через Tor/Bluetooth	Нихромасштабируемый, для активистов

4.3. Проблемы федерации

Спам и abuse: как блокировать spam@evil.net без центрального бан-листа?
→ Решение: reputation системы (например, Matrix использует m.policy.rule.* events).
Производительность: задержка при server1 → server2 → server3.
→ Оптимизация: geo-routing, caching шлюзов.
Идентификация: @user:server.org неудобен.
→ Решение:
- Decentralized Identifiers (DID) — did:elem:EiD...,
- Handle-системы (как @user в Bluesky),
- ENS-имена (в Web3: timur.eth → @timur:matrix.org).

Федерация — не идеал, но единственный путь к цифровому суверенитету. Её успех зависит от UX: если пользователь не замечает разницы — она приживётся.

5. Будущее мессенджеров: AI, Web3, AR, и за пределами экрана

5.1. AI-интеграция: от автозамены до со-пилотов

Современные мессенджеры уже используют:

NLP для модерации: распознавание hate speech, CSAM (Telegram, Discord).
Генерация ответов: «Smart Reply» в WhatsApp (на базе Lite-BERT).
Контекстные боты: Notion AI внутри чатов — суммирует историю, генерирует задачи.

Ближайшее будущее:

Персональные агенты: LLM, привязанный к вашей истории, который:
— напоминает о договорённостях («Ты обещал прислать ТЗ до 15:00»),
— фильтрует шум («Пропустить 12 сообщений в группе “Закупки”, показать только решения»),
— генерирует черновики («Сформулируй официальный ответ для клиента»).

Требования: on-device inference (MLC LLM, Core ML), privacy-preserving training (Federated Learning).

5.2. WebRTC и P2P: возвращение к корням

WebRTC позволяет:

Голос/видео без сервера-ретранслятора (STUN/TURN только для NAT-traversal),
Прямой файловый обмен (WebTorrent + WebRTC Data Channels),
Оффлайн-чаты через Bluetooth/WiFi Direct (Briar, Bridgefy).

Telegram экспериментирует с P2P-звонками в настольной версии — задержка падает с 200 мс до 40 мс.

5.3. Web3 и мессенджеры

Идентификация через кошелёк:
0xAbC... → ENS-имя → профиль в мессенджере (Status.im, TON Sites).
Оплата внутри чата:
Telegram Stars → оплата ботов, подписок, контента.
Децентрализованное хранение:
История в IPFS/Filecoin, ключи в Ceramic Network.

5.4. AR/VR: чаты в 3D-пространстве

Meta (Horizon Worlds), Microsoft Mesh — строят «пространственные чаты»:

Аватары с губной синхронизацией,
Объекты в чате — 3D-модели, таблицы, код,
Голосовой ввод + жесты как интерфейс.

Проблема: latency. Для плавного AR требуется <20 мс — только edge-compute (5G MEC).

Мессенджеры​

1. Исторический контекст​

1.1. Ранние системы​

1.2. Эра веб-платформ: Jabber/XMPP, Facebook Chat​

1.3. Мобильная революция: WhatsApp, Viber, WeChat​

1.4. Современный этап: Telegram, Signal, Matrix​

2. Что такое мессенджер​

3. Система мгновенных сообщений (IM)​

3.1. Клиент (Client)​

3.2. Транспортный уровень​

3.3. Сервер (Backend)​

3.4. Протокол обмена​

4. Как работает доставка сообщения: пошаговый разбор​

5. Сквозное шифрование (End-to-End Encryption, E2EE)​

5.1. Что это — и чего это не даёт​

5.2. Реализации​

6. Переписка, история, группы и каналы: модели данных​

6.1. Переписка (chat/dialog)​

6.2. Группы​

6.3. Каналы​

7. Как получить, установить и использовать мессенджер​

7.1. Способы получения​

7.2. Первый запуск: что происходит «под капотом»​

7.3. Базовые операции — как они реализованы​

Часть 2. Глубокая архитектура мессенджеров​

1. Сравнительный анализ протоколов: MTProto, Signal Protocol и Matrix (Olm/Megolm)​

1.1. MTProto 2.0 (Telegram)​

1.2. Signal Protocol (WhatsApp, Signal, Google Messages)​

1.3. Matrix: Olm (1:1) и Megolm (группы)​

2. Боты: от простых команд до автономных агентов​

2.1. Модели взаимодействия​

2.2. Архитектура бота на примере Telegram Bot API​

2.3. Продвинутые сценарии​

3. Безопасность мессенджеров: не только шифрование​

3.1. Уязвимости транспортного уровня​

3.2. Утечки метаданных​

3.3. Атаки на клиент​

4. Федерация и децентрализация​

4.1. Что такое федерация?​

4.2. Реализации​

4.3. Проблемы федерации​

5. Будущее мессенджеров: AI, Web3, AR, и за пределами экрана​

5.1. AI-интеграция: от автозамены до со-пилотов​

5.2. WebRTC и P2P: возвращение к корням​

5.3. Web3 и мессенджеры​

5.4. AR/VR: чаты в 3D-пространстве​